home *** CD-ROM | disk | FTP | other *** search
- Path: mail2news.demon.co.uk!genesis.demon.co.uk
- From: Lawrence Kirby <fred@genesis.demon.co.uk>
- Newsgroups: comp.lang.c
- Subject: Re: Alignment restrictions...
- Date: Wed, 10 Jan 96 14:55:37 GMT
- Organization: none
- Message-ID: <821285737snz@genesis.demon.co.uk>
- References: <DKxHxG.EK1@ridgecrest.ca.us> <821232137snz@genesis.demon.co.uk> <DKyBK5.5r6@ridgecrest.ca.us>
- Reply-To: fred@genesis.demon.co.uk
- X-NNTP-Posting-Host: genesis.demon.co.uk
- X-Newsreader: Demon Internet Simple News v1.27
- X-Mail2News-Path: genesis.demon.co.uk
-
- In article <DKyBK5.5r6@ridgecrest.ca.us>
- mcclung@owens.ridgecrest.ca.us "Scott McClung" writes:
-
- >In article <821232137snz@genesis.demon.co.uk>,
- >Lawrence Kirby <fred@genesis.demon.co.uk> wrote:
- >
- >> What are the byte order conventions in the 'image file'? What you
- >> have here assumes big endian while the code at the top just assumes
- >> the byte order is the same as the target variable. In the latter
- >> case this problem is easily solved by:
- >>
- >> memcpy(&value, ptr, sizeof value);
- >
- >Big endian. The files are RLA images, animation frames, generated
- >by Composer from WaveFront. The program converts RLA to YUV.
-
- In that case your shift/or version is more portable since it doesn't depend
- on the byte order of the system.
-
- >
- >> I suspect that the tailored inline code that a good compiler can
- >> generate for memcpy, especially with a fixed, small size would be
- >> difficult to beat.
- >
- >I guess I'll check the assembly output of the compiler to make sure
- >that it's really putting the memcpy() calls inline.
-
- gcc will certainly inline standard library functions such as memcpy, so
- long as you have suitable optimisation options selected.
-
- --
- -----------------------------------------
- Lawrence Kirby | fred@genesis.demon.co.uk
- Wilts, England | 70734.126@compuserve.com
- -----------------------------------------
-